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1. Real parties in interest (37 C.F.R. § 41.37 (c) (1) (i)). 

The sole inventor, Lan Ngoc Vu ("Applicant"), has assigned all right, title and interest in 
and to the present application ("Application"). Accordingly, the real party in interest in 
this appeal is Web Office, Inc, a corporation organized under the laws of the State of 
Texas, having its principal place of business at 9211 Waterford Centre Blvd., Suite 250, 
Austin, TX 78758. 

2. Related appeals and interferences (37 C.F.R. § 41.37 (c) (1) (ii)). 

Applicant is not aware of any appeals or interferences that will directly affect, or be 
directly affected by, or have a bearing on, the Board's decision in this appeal. 

3. Status of claims (37 C.F.R. § 41.37 (c) (1) (iii)). 

The Application, as filed, had eight (8) claims (claims 1-8). Claims 7 and 8 have been 
canceled. There are six (6) claims presently pending in the application (claims 1-6). 
Claims 1-6 are presently being appealed. 

4. Status of amendments (37 C.F.R. § 41.37 (c) (1) (iv)). 

All amendments filed subsequent to final rejection have been entered. 

5. Summary of claimed subject matter (37 C.F.R. § 41.37 (c) (1) (v)). 

The following summary is provided to give the Board the ability to conveniently review 
particular embodiments of the claims on appeal as described in the Application, but this 
summary is not intended to limit the scope of the claimed invention. 

In the Application's specification ("Specification"), Applicant has %x italicize [d] the first 
occurrence of each special term of art which should be familiar to those skilled in the art 
of network communication systems." (See, Specification, page 1, lines 18-20.) One such 
term was "multi-casting". (See, Specification, page 2, line 22.) Accordingly, Applicant's 
claims 1-6, incorporating as each does the term "multi-casting" or "multi-cast", are 
expressly limited to that application. As explained in the Application, "multi-casting [is] 
used for simultaneously delivering], point- to-multi-point, the same content to multiple 
clients." (See, Specification, page 2, lines 22-24.) As also explained in the Application, 
multi-casting is typically used to simultaneously cast live content in a continuous stream 
from the content server to all subscribed clients. (See, Specification, page 4, line 25, 
through page 5, line 3.) 

In independent claim 1, a system for multi-tier multi-casting via a public communication 
network 6 is claimed. This system is comprised of three distinct functional units: (i) a 
content server 4 adapted to multi-cast predetermined content via the public 
communication network 6, wherein the content server 4 comprises a first tier; (ii) a first 
client server 12 adapted to receive the content multi-cast by the content server 4 via the 
public communication network 6, and to multi-cast the received content via a first private 
communication network (not expressly enumerated in Fig. 1, but comprising the network 
connections between the first client server 12 and the set of clients J through clientj: 
generally within the illustrated business site 10), wherein the first client server 12 
comprises a second tier; and (iii) a first client (any of clientj through clientj*) adapted to 
receive the content multi-cast by the first client server 12 via the first private 
communication network. In dependent claim 2, a second client server (not separately 
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enumerated but equivalent to first client server 12) provides multi-cast rebroadcast of 
content provided by the content server 4 to a second client (not separately enumerated but 
equivalent to any of client J through clientj:). In dependent claim 3, a second client (not 
separately enumerated but equivalent to any of clientj through clientj") is added to the 
second private communication network so as to receive the multi-cast rebroadcast by the 
second client server of content provided by the content server 4. In dependent claim 4, a 
third client (not separately enumerated but equivalent to any of clientj through client_r) 
is added to the first private communication network so as to receive the multi-cast 
rebroadcast by the first client server of content provided by the content server 4. In each 
of claims 1-4, the content server 4 is aware of, and multi-casts directly to, only the client 
server(s); conversely, each client is aware of, and receives multi-cast content from, only 
the respective client server. In this system, the content server 4 is relieved by each client 
server 12 of the bandwidth required to service each of the latter's clients, especially with 
respect to transmission errors (see, Specification, page 9, lines 20-30, and Fig. 4). In 
addition, each client server 12 can independently provide locally enhanced services such 
as time-shifting (see, Specification, page 8, lines 17-28, and page 9, lines 13-19), 
whereby, for example, a multi-cast session originating during normal business hours in 
one time zone can be re-multi-cast during normal business hours of a different time zone 
half-way around the world. 

In independent claim 5, a method for multi-tier multi-casting via a public communication 
network 6 is claimed. This method is comprised of three distinct steps: (i) multi-casting 
predetermined content via the public communication network 6 (see, Specification, page 
7, line 18, through page 8, line 10); (ii) receiving the content multi-cast via the public 
communication network 6, and multi-casting the received content via a first private 
communication network (see, Specification, page 8, lines 11-10); and (iii) receiving the 
content multi-cast via the first private communication network. The details of the 
claimed method are illustrated in flow diagram form in Figs. 3-5, and described in the 
Specification from page 8, line 29, through page 10, line 13. In dependent claim 6, the 
method of claim 5 is enhanced to include the ability to: (i) receive the content multi-cast 
via the public communication network 6, and multi-cast the received content via a second 
private communication network (not separately enumerated but equivalent to the first 
private communication network); and (ii) receive the content multi-cast via the second 
private communication network. In each of claims 5 and 6, the source of the original 
content is aware of, and multi-casts directly to, only those "public" recipients connected 
directly to the public communication network; conversely, each "private" recipient is 
aware of, and receives multi-cast content from, only the respective public recipient. In 
accordance with this method, the content source (e.g., the content server 4) is relieved by 
each public recipient (e.g., client server 12) of the bandwidth required to service each of 
the private recipients (e.g., any of clientj through clientj), especially with respect to 
transmission errors (see, Specification, page 9, lines 20-30, and Fig. 4). In addition, each 
public recipient (e.g., client server 12) can independently provide enhanced services such 
as time-shifting (see, Specification, page 9, lines 13-19). 
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6. Grounds of rejection to be reviewed on appeal (37 C.F.R. § 41.37 (c) (1) (vi)). 

Claims 1-6 were finally rejected in the Office Action dated 2 September 2004 (Paper 6 -- 
"Action") under 35 U.S.C. § 102 (e) as being anticipated by Huang, et al, U.S. Patent 
No. 6,292,835 ("Huang"). 

With respect to claims 1 and 5, the Examiner has asserted: 

"Huang teaches a method and system (abstract) for multi-tier multi-casting 
via a public communication network (col. 1, linel - col. 3, line 25), 
comprising: 

"a. A content server (Fig. 1, #108) adapted to multi-cast predetermined 
content (col. 4, lines 3-5) via the public communication network (Fig. 1, 
#111), wherein the content server comprises a first tier (Fig. 1 ; S); 

"b. A first client server (Fig. 1, #105) adapted to receive the content 
multi-cast by the content server via the public communication network 
(col. 4, lines 20-30), and to multi-cast the received content (col. 4, lines 
28-45) via a first private communication network (Fig. 1, #110), wherein 
the first client server comprises a second tier (Fig. 1; P); and 

n c. A first client (Fig. 1, #101) adapted to receive the content multi-cast 
by the first client server via the first private communication network (col. 
4, lines 28-45)." (See, Action, page 5, lines 1-11.) 

With respect to claims 2 and 6, the Examiner has asserted: 

"Huang teaches that the method and system further comprises: 

"a. A second client server adapted to receive the content multi-cast by the 
content server via the public communication network, and to multi-cast 
the received content via a second private communication network, wherein 
the first and second client servers comprises said second tier (col. 4, lines 
18-21); and 

"b. A second client adapted to receive the content multi-cast by the 
second client server via the second private communication network (Fig. 
1, #102)." (See, Action, page 5, lines 12-18.) 

With respect to claim 3, the Examiner has asserted that "Huang teaches a third client 
adapted to receive the content multi-cast by the second client server via the second 
private communication network (Fig. 1, #103)." (See, Action, page 5, lines 19-20.) 

With respect to claim 4, the Examiner has asserted that "Huang teaches a fourth client 
adapted to receive the content multi-cast by the first client server via the first private 
communication network (Fig. 1, #104)." (See, Action, page 5, lines 21-22.) 

7. Argument (37 C.F.R. § 41.37 (c) (1) (vii)). 

In the Action, the Examiner rejected claims 1-6 under 35 U.S.C. § 102 (e) as being 
anticipated by Huang. In support of this rejection, the Examiner has asserted that the on- 
demand, point-to-point content delivery method of operation of Huang is "multi-casting". 
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If, as Applicant respectfully submits, this assumption is incorrect, then the rejection of 
claims 1-6 is without support and should be overruled by the Board. 

7. 1 . Multi-casting is quite different from uni-casting. 

In the Action, the Examiner has asserted that "Huang teaches a method and system 
(abstract) for multi-tier multi-casting via a public communication network", citing in 
support of such assertion Huang, col. 1, line 1 - col. 3, line 25. Applicant respectfully 
disagrees with such assertion in that there is no suggestion, much less teaching, in Huang 
relating to multi-casting, whether single-tier or multi-tier. 

As noted in Section 5, above, Applicant has chosen to be his own lexicographer by 
expressly incorporating a number of definitions into the introductory portions of the 
present application. In particular, Applicant has declared that, in the context of the 
invention claimed in this Application, "multi-casting [is] used for simultaneously 
deliver [ing], point-to multi-point [sic], the same content to multiple clients." (See, 
Specification, page 2, lines 22-24.) As explained in the present application, multi-casting 
is typically used to simultaneously cast live content in a continuous stream from the 
content server to all subscribed clients. (See, Specification, page 4, line 25, through page 
5, line 3.) Applicant's definition, and consistent use of, the term "multi-casting" is in 
conformance with industry standards: 

Wikipedia, a popular on-line encyclopedia, first describes "unicast" as follows: 

"In computer networks, unicast is the sending of information packets to a 
single destination. Unicast' is derived from the word broadcast, as 
unicast is the extreme opposite of broadcasting. In computer networking, 
multicasting is used to regain some of the efficiencies of broadcasting." 

http://en.wikipedia.org/wiki/Unicast 

then describes "multicast" as follows: 

"Multicast is the delivery of information to a group of destinations 
simultaneously using the most efficient strategy to deliver the messages 
over each link of the network only once and only create copies when the 
links to the destinations split." 

http://en.wikipedia.org/wiki/Multicast 

In Webopedia, another on-line encyclopedia, "unicast" is defined as follows: 

"Communication that takes place over a network between a single sender 
and a single receiver." 

http://www.webopedia.eom/TERM/U/unicast.html 
whereas, "multicast" is defined as follows: 

"To transmit a single message to a select group of recipients. A simple 
example of multicasting is sending an e-mail message to a mailing list. 
Teleconferencing and videoconferencing also use multicasting, but require 
more robust protocols and networks. 
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"Standards are being developed to support multicasting over a TCP/IP 
network such as the Internet. These standards, IP Multicast and Mbone, 
will allow users to easily join multicast groups. 

"Note that multicasting refers to sending a message to a select group 
whereas broadcasting refers to sending a message to everyone connected 
to a network." (Note: links are also provided for instructive white papers 
by 3COM and Cisco.) 

http://www.webopedia.eom/TERM/M/multicast.html 

The Linux Documentation Project (generally referred to as "TLDP"), a leader in the field 
of open source software, describes "multicast" as follows: 

"Multicast is... a need. Well, at least in some scenarios. If you have 
information (a lot of information, usually) that should be transmitted to 
various (but usually not all) hosts over an internet, then Multicast is the 
answer. One common situation in which it is used is when distributing real 
time audio and video to the set of hosts which have joined a distributed 
conference. 

"Multicast is much like radio or TV in the sense that only those who have 
tuned their receivers (by selecting a particular frequency they are 
interested on) receive the information. That is: you hear the channel you 
are interested in, but not the others." 

They then go on to explain, in detail, "The problem with Unicast". 
http://www.tldp.org/HOWTO/Multicast-HOWTO-l .html#ssl . 1 

In an Introduction to Multicasting, the Networks and Telecommunications Research 
Group in the Department of Computer Science at Trinity College, Dublin, Ireland, states: 

"Most high-level network protocols (such as the ISO Transport Protocols 
or TCP or UDP) only provide a unicast transmission service. That is, 
nodes of the network only have the ability to send to one other node at a 
time. 

"All transmission with a unicast service is inherently point-to-point. If a 
node wants to send the same information to many destinations using a 
unicast transport service, it must perform a replicated unicast, and send N 
copies of the data to each destination in turn. 

"A better way to transmit data from one source to many destinations is to 
provide a multicast transport service. With a multicast transport service, a 
single node can send data to many destinations by making just a single call 
on the transport service ... ." 

http://ntrg.cs.tcd.ie/undergrad/4ba2/multicast/ 
7.2. Huang does not multi-cast. 

Despite the Examiner's continued assertions to the contrary, Applicant respectfully 
submits that nothing in Huang either teaches or suggests that the content updating process 
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described therein can be used to simultaneously deliver the same content to multiple 
clients. By equating "object pushing" with "multi-casting", the Examiner has ignored 
several distinctive differences between these technologies, especially the simultaneity 
aspect. Huang describes "object pushing" as follows: 

"Traditionally, object retrieval on the web is based on pull technology. In 
this approach, a web user retrieves a web object by clicking an icon or a 
hyperlink through a web browser, which then establishes a network 
connection to a web content provider and proceeds to download and 
display the requested object. If the requested information is retrieved 
through a slow network, a noticeable latency may occur at the user end. 
To avoid the long wait for pulling the requested documents, an alternative 
is to have the server push the information to the users based on pre- 
specified user preferences or profiles as soon as relevant information 
becomes available. The users therefore receive the requested information 
without having to wait. Currently, most push technologies are based 
on background pull where a software application, executing on behalf 
of the user, periodically pulls the requested objects in the background. 

"In ... object pushing in WWW as well as other systems that require 
data be continually sent from the servers to the clients, an important 
consideration is when and how often the client contents are updated. 
Ideally, one would like the client contents to be updated whenever their 
corresponding server data changes. However, this is impractical as 
frequent updates from a large number of clients may demand a very high 
network bandwidth capability not available in most organizations that run 
the relevant systems such as object pushing on web or data replication in 
distributed databases. In practice, most of these systems adopt a 
default periodical update mechanism in which each client sets 
beforehand fixed update schedules, one for each server it subscribed 
to. In addition, many of these systems also provide a demand-driven 
update mechanism such that a client can immediately request an 
update from a certain server if an urgent need arises. 

"While the pure demand-driven update scheme can be too costly in terms 
of bandwidth usage, the regularly scheduled updates provide flexibility in 
preserving bandwidth. However, it may be important for clients to set an 
appropriate update frequency for each server to which they are subscribed. 
If the frequency is too high, network bandwidth may be overflowed with 
the update traffic; if the frequency is too low, the information maintained 
by the clients may become too outdated. In the case of object push in 
WWW, it has been found that users tend to inadequately specify their 
preferences for updates with high frequencies such that many corporate 
gateways are often flooded with push traffic. 

"To alleviate this push overflow problem, push product vendors have 
developed proprietary proxy server software. In general, these proxy 
servers cache recently retrieved push objects. For each push request, these 
proxy servers desirably search their cache for the requested objects. If an 
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object is found in the cache, that object is sent back to the user who made 
the request. If an object is not found in cache, or if the found object is 
considered too old, these proxy servers may relay a background pull to 
the original content provider to retrieve the requested object via 
corporate gateways. This approach can improve the gateway traffic 
because some client requests will involve only the retrieval of 
information from the proxy server's cache, and the number of cross- 
gateway update requests will decrease as a result. 

"In this proxy approach, the proxy updates have replaced the client 
updates in direct contact with the servers, and it is the proxy's 
responsibility to keep the contents stored in their caches up to date in 
order to reflect the new changes from the servers. When more 
corporate users are subscribing to the increasing number of channels that 
publish push objects (as is the current trend), the proxy-based update 
traffic can still flood the gateways if it does not take into consideration the 
gateway traffic condition. The same analogy can also be applied to the 
problem of periodical data replication beyond local gateways in a 
distributed database system." (Huang, col. 1, line 59 - col. 3, line 5.) 
(Emphasis added.) 

. "In a conventional proxy-based object pushing or data replication system, 
a proxy caches one newest copy for each object that the proxy received 
from the servers. Aside from the objects themselves, the proxy typically 
keeps meta information for each cached object which indicates when the 
object was created. This information tells the proxy how current each 
cached object is. Upon receiving an update request from a client the 
proxy searches its cache. If the requested object is found in the cache, 
the proxy determines the currency of the object based on the creation 
time of the cached object If the proxy determines the found object is 
current enough, this object is returned to the client who made the 
update request without incurring update traffic across the gateway. 
If the proxy determines that the found object is too outdated, or if the 
requested object is not located within the proxy's cache, then the 
proxy sends an update request to the corresponding server through 
the gateway on behalf of the requesting client When the server sends 
back the requested object to the proxy, the proxy replaces the older 
copy of this object (if it exists) with the new one in its cache, updates 
the meta information (such as creation time) associated with this 
object and also sends a new copy to the requesting client ." (Huang, 
col. 4, lines 22-44.) ( Emphasis added .) 

As is clear from the above, Huang's system does not employ multi-casting because, if it 
did so, updating would be wholly unnecessary - the essence of multi-casting is that all 
recipients are simultaneously receiving CURRENT contents. 

Another concept, important in Huang but irrelevant in multi-casting, is subsetting: 
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"Each server 107-109 is a data source that manages a set of dynamically 
changing information which can be of any of the multimedia types (e.g., 
text, binary file, image, audio and video clip). Each client 101-104 
maintains subsets of information from one or more server data 
sources. In order to keep its information up to date, each client 101- 
104 sends update requests periodically to the servers where this clients 
information was originated . These update requests however do not go to 
the corresponding servers directly. Instead, they go through proxy 105 
which serves as an intermediary between clients 101-104 and servers 107- 
109. Proxy 105 determines if client update requests should be relayed to 
corresponding servers or if potentially older copies of the requested 
objects cached previously by the proxy should be transmitted to clients 
making update requests." (Huang, col. 4, lines 2-17. Emphasis added.) 

Since Huang envisions each client being interested in only a unique subset of available 
channel information, multi-casting the full content to every client just for selective 
extraction would be a huge waste of communication bandwidth, computational power, 
and storage capacity. 

Yet another concept, essential to multi-casting but unsolved by Huang, is simultaneity: 

"From a client's point of view, the highest currency of an object at the 
client end can be achieved by the proxy servicing an update request every 
time the server updates its corresponding object (i.e., the proxy update 
schedule matches the server update schedule exactly). If the gateway (or 
in general the network) bandwidth availability discourages such frequent 
updates, as is usually the case, then the proxy may skip some server 
updates and may, instead, return less up-to-date copies of objects to the 
requesting clients in-between two consecutive proxy updates. In 
accordance with an exemplary embodiment of the present invention, a 
method is deployed to measure state of being out-of-date for objects 
received from the proxies to the clients. Furthermore, an objective 
function is formulated, based on the measured out-of-date status of objects 
received by the clients, to compute a proxy update schedule for each 
channel by minimizing the overall outrof-date degree. The formulated 
objective function is then solved by known techniques." (Huang, col. 5, 
lines 47-64.) (Emphasis added.) 

Rather than provide some method or system for receiving and relaying to all clients a 
stream of current information in "real time", i.e., as it is being multi-cast by a content 
server, Huang offers, at best, a scheme to compute, using a "formulated objective 
function", a proxy update schedule for retrieving only selected bits and pieces of the total 
available content, for subsequent relay, on demand, to particular requesting clients. Thus, 
in Huang, multi-casting is used in neither tier, server-to-proxy or proxy-to-client. 

In the Action, the Examiner has asserted that Huang's Dynamic Update process is 
equivalent to multi-casting. (Action, page 3, lines 5-8.) However, this process relates 
primarily to dynamically-modifying the update schedule based on certain system 
parametrics: 
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"Dynamic update procedure 207 can be dynamically invoked by a proxy 
to process proxy updates for channels with high user interest before their 
respective next scheduled proxy updates." (Huang, col. 5, lines 19-22.) 

"An alternative embodiment of the present invention contemplates a 
procedure that allows a proxy to, based on client interests and available 
bandwidth, dynamically update channels before their respective next 
scheduled proxy updates." (Huang, col. 9, lines 14-17.) 

However, the actual update process is wholly conventional: 

"Finally, the proxy perform a dynamic update for each of the selected 
channels (805)." (Huang, col 10, lines 15-16.) 

Taking all this into consideration, Applicant respectfully submits that Huang's proxy 
operates in a conventional point-to-point mode to: (i) locally "cache" copies of "subsets" 
of larger objects maintained on remote servers; (ii) provide requested portions of the 
cached content in response to client-generated demands; and, (iii) "update" the cached 
copies according to a set of predetermined "obsolescence" rules. While Huang may be 
advantageously used to maintain local coherency with a slowly changing content base, 
such as a Lotus Notes database, it is neither adapted to, nor intended to, maintain local 
synchronicity with a continuously changing content stream. In that Huang "pulls" new 
content either on a particular schedule or in response to client "demand", it is simply not 
adapted to perform even uni-casting, much less multi-casting. 

7.3. Claim 1 is not anticipated by Huang under 35 U.S.C. §102 (e). 

Claim 1 is not anticipated by Huang under 35 U.S.C. §102 (e) for the following reasons: 

a. The Huang system, as disclosed, cannot multi-tier multi-cast via a public 
communication network (Application, claim 1, lines 1-2); 

b. The Huang servers 107-109, as disclosed, are not adapted to multi-cast 
predetermined content via the public communication network, wherein each server 
comprises a first tier (Application, claim 1, lines 3-5); 

c. The Huang proxy 105, as disclosed, is not adapted to receive the content multi- 
cast by the servers via the public communication network, and to multi-cast the received 
content via a first private communication network, wherein this first proxy comprises a 
second tier (Application, claim 1, lines 6-9); and 

d. The Huang clients 101-104, as disclosed, are not adapted to receive the content 
multi-cast by the first proxy via the first private communication network (Application, 
claim 1, lines 10-11). {Emphasis added.) 

1 A. Claim 2 is not anticipated by Huang under 35 U.S.C. §102 (e). 

Claim 2 is not anticipated by Huang under 35 U.S.C. §102 (e) for the following reasons: 

a. The Huang proxy 105, as disclosed, is not adapted to receive the content multi- 
cast by the servers via the public communication network, and to multi-cast the received 
content via a second private communication network, wherein the first proxy and this 
second proxy comprises a second tier (Application, claim 2, lines 2-5); and 
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b. The Huang clients 101-104, as disclosed, are not adapted to receive the content 
multi-cast by the second proxy via the second private communication network 
(Application, claim 2, lines 6-7). {Emphasis added.) 

7.5. Claim 3 is not anticipated by Huang under 35 U.S.C. §102 (e). 

Claim 3 is not anticipated by Huang under 35 U.S.C. §102 (e) for the following reason: 

a. The Huang clients 101-104, as disclosed, are not adapted to receive the content 
multi-cast by the second proxy via the second private communication network 
(Application, claim 3, lines 2-3). {Emphasis added.) 

7.6. Claim 4 is not anticipated by Huang under 35 U.S.C. §102 (e). 

Claim 4 is not anticipated by Huang under 35 U.S.C. §102 (e) for the following reason: 

a. The Huang clients 101-104, as disclosed, are not adapted to receive the content 
multi-cast by the first proxy via the first private communication network (Application, 
claim 4, lines 2-3). {Emphasis added.) 

1.1. Claim 5 is not anticipated by Huang under 35 U.S.C. §102 (e). 

Claim 5 is not anticipated by Huang under 35 U.S.C. §102 (e) for the following reasons: 

a. The Huang method, as disclosed, does not multi-tier multi-cast via a public 
communication network (Application, claim 5, lines 1-2); 

b. The Huang method, as disclosed, does not multi-cast predetermined content via 
the public communication network (Application, claim 5, line 3); 

c. The Huang method, as disclosed, does not receive the content multi-cast via the 
public communication network, and multi-cast the received content via a first private 
communication network (Application, claim 5, lines 4-6); and 

d. The Huang method, as disclosed, does not receive the content multi-cast via the 
first private communication network (Application, claim 5, line 7). {Emphasis added.) 

7.8. Claim 6 is not anticipated by Huang under 35 U.S.C. §102 (e). 

Claim 6 is not anticipated by Huang under 35 U.S.C. §102 (e) for the following reasons: 

a. The Huang method, as disclosed, does not receive the content multi-cast via the 
public communication network, and multi-cast the received content via a second private 
communication network (Application, claim 6, lines 2-4); and 

b. The Huang method, as disclosed, does not receive the content multi-cast via the 
second private communication network (Application, claim 6, lines 5-66). {Emphasis 
added.) 

7.9. The Standard of Patentability Under 35 U.S.C. §102 (e). 

With respect to the rejection of claims 1-6 as being anticipated by Huang, MPEP §2131 
provides: 

"A claim is anticipated only if each and every element as set forth in the claim is 
found, either expressly or inherently described in a single prior art reference. 
Verdegaal Bros, v Union Oil Co. of California, 814 F.2d 628, 631, 2 USPQ2d 
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1051, 1053, (Fed. Cir. 1987). "The identical invention must be shown in as 
complete detail as contained in the ... claim." Richardson v. Suzuki Motor Co., 
868 F.2d 1226, 1236, 9 USPQ2d 1913, 1920 (Fed. Cir. 1989). The elements must 
be arranged as required by the claims." 

Since, as Applicant has demonstrated above, "each and every element as set forth the 
claim[s]" are not "found, either expressly or inherently described in a single prior art 
reference", the rejection of claims 1-6 under 35 U.S.C. §102 (e), based on Huang, is not 
well founded. Accordingly, claims 1-6 are allowable over. Huang under 35 U.S.C. 102 
(e). Therefore, Applicant respectfully submits that claims 1-6 are allowable over the 
cited references under 35 U.S.C. §102 (e). 

8. Conclusion . 

For at least the reasons given above, the Applicant respectfully requests reconsideration 
and allowance of claims 1-6, and respectfully request that the pending patent application 
be promptly passed to issue. 

Respectfully submitted, 
Lan Ngoc Vu ^ 




Attorney for Applicant 
Reg. No. 27,362 
Ph: 512/858-7453 
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9. Claims Appendix (37 C.F.R. § 41.37 (c) (1) (viii)). 
The text of each claim involved in the appeal is as follows: 

1. (Original) A system for multi-tier multi-casting via a public communication network, 
comprising: 

a content server adapted to multi-cast predetermined content via the public 
communication network, wherein the content server comprises a first tier; 

a first client server adapted to receive the content multi-cast by the content server via 
the public communication network, and to multi-cast the received content via a 
first private communication network, wherein the first client server comprises a 
second tier; and 

a first client adapted to receive the content multi-cast by the first client server via the 
first private communication network. 

2. (Original) The system of claim 1 further comprising: 

a second client server adapted to receive the content multi-cast by the content server 
via the public communication network, and to multi-cast the received content 
via a second private communication network, wherein the first and second client 
servers comprise said second tier; and 

a second client adapted to receive the content multi-cast by the second client server 
via the second private communication network. 

3. (Original) The system of claim 2 further comprising: 

a third client adapted to receive the content multi-cast by the second client server via 
the second private communication network. 

4. (Previously amended) The system of claim 1 further comprising: 

a second client adapted to receive the content multi-cast by the first client server via 
the first private communication network. 
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5. (Original) A method for multi-tier multi-casting via a public communication network, 
the method comprising the steps of: 

multi-casting predetermined content via the public communication network; 

receiving the content multi-cast via the public communication network, and multi- 
casting the received content via a first private communication network; and 

receiving the content multi-cast via the first private communication network. 

6. (Original) The method of claim 5 further comprising: 

receiving the content multi-cast via the public communication network, and multi- 
casting the received content via a second private communication network; and 

receiving the content multi-cast via the second private communication network. 
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